Herzlich willkommen zur Vorlesung Konzeptionelle Modellierung.

Wir wiederholen wieder kurz, was wir beim letzten Mal gemacht haben.

Da ging es darum, ER-Diagramme abzubilden auf eine möglichst äquivalente Menge von Tabellen, Relationen.

Wir haben das zunächst an einem Beispiel gemacht und dann haben wir aber auch formal definiert,

wie man schrittweise vorgeht, wenn man so ein ER-Diagramm überführen möchte in eine Menge von Tabellen, möglichst verlustfrei.

Im Wesentlichen sind wir da mit folgenden Regeln rausgekommen.

Entitytypen, oder für Entitytypen definieren wir typischerweise jeweils eine eigene Tabelle.

Erstmal nennen wir sie Entitytabelle.

Dann haben wir uns gefragt, was machen wir mit den Beziehungstypen.

Wir haben im Relationenmodell nur ein Modellierungskonstrukt, wir müssen alles in Tabellen abbilden.

Bei Beziehungstypen haben wir jetzt die Wahl, entweder packen wir den Beziehungstyp auch in eine eigene Tabelle rein.

Oder bei bestimmten Beziehungstypen müssen wir das nicht unbedingt machen,

da können wir auch mit Fremdschlüsselbeziehungen arbeiten.

Da packen wir also in die bestehende Tabelle, die wir bereits für unsere Entitys haben,

zusätzliche Fremdschlüssel-Attribute rein, die dann auf andere Tabellen verweisen.

Also ein 1 zu 1 oder ein 1 zu n-, den können wir mithilfe von Fremdschlüsseln abbilden.

Wir können aber jeden beliebigen Beziehungstyp auch mit einer eigenen Tabelle abbilden und M zu N Beziehungstypen,

für die müssen wir auf jeden Fall eine eigene Tabelle einführen.

So, was machen wir mit mehrstelligen Beziehungstypen? Für die bilden wir auch jeweils eine eigene Tabelle.

Die Frage ist auch, wie sieht jetzt der Premierschlüssel dieser neuen Tabelle aus?

defendedξ...

ISSA➡ schon НА5 ganz auf xn

weil es so Sarikos一個 줄 bis gut

wenn das ein Allgemeiner Beziehungstyp ist, ohne irgendwelche Einschränkungen

ohne irgendwelche Sch taller so wie dieser hier

Dann ist die Tabelle, die jetzt diesen ternären Beziehungstyp repräsentiert.

Dann sieht die so aus.

Für jeden beteiligten Entitytyp haben wir einen Fremdschlüssel in dieser Tabelle drin.

Und die Attribute, die hier noch zu diesem Beziehungstyp dazugehören,

die haben wir natürlich hier auch mit drin.

Das ist hier nur eins, das Attributmenge, das taucht da unten auch auf.

Der Primärschlüssel dieser neuen Tabelle, das ist die Kombination aus all diesen Fremdschlüsseln.

Und jede Zeile in dieser neuen Tabelle, die repräsentiert genau eine Ausprägung dieses ternären Beziehungstyps.

Also eine Lieferung, ein Lieferant liefert ein bestimmtes Teil an ein bestimmtes Projekt.

Das ist genau eine Zeile in dieser Tabelle.

Und hier haben wir genau einen Verweis auf einen Lieferanten, auf ein Projekt und einen Schlüssel.

Und die drei zusammen identifizieren die Zeile.

Das ist hier der Primärschlüssel.

So, wenn jetzt da eine Eins an einer Kante steht, haben wir gesagt, was bedeutet das?

Damit definieren wir eine funktionale Abhängigkeit, ein Constraint, eine Integritätsbedingung,

von der wir wollen, dass das Datenbanksystem die sicherstellt.

Und in diesem Fall, wenn hier beim Lieferanten eine Eins steht,

dann bedeutet, pro Projekt und Teil gibt es nur einen Lieferanten.

Was bedeutet das jetzt für unsere neue Tabelle hier?

Wenn es pro Projekt und Teil nur einen Lieferanten gibt,

dann können wir nicht mehr Lieferant, Projekt und Teil zusammen als Primärschlüssel nehmen,

weil das wäre nicht mehr minimal.

Ein Primärschlüssel muss immer minimal sein, das muss zumindest ein Schlüsselkandidat sein.

Das heißt, wir dürfen kein Attribut da weglassen können, ohne die

identifizierende Eigenschaft zu verlieren. Das würden wir aber hier, wenn